Engineering

Search that finds the sentence

Document search returns documents. People do not want a document. They want the line that answers the question, and to know whether it is still true.

Sam Okafor Search lead Jul 14, 2026 · 4 min read
A wooden library card catalog with one drawer pulled open in a sunlit reading room

Most wiki search works the way it did in 2005. You type words, it finds pages that contain those words, and it ranks them by how often the words appear. You get a list of twenty documents. Somewhere in one of them is the sentence you wanted.

When we watched people use search in Quill’s first version, the pattern was always the same: search, open the first result, press Command-F, search again inside the page. The page was never the answer. The sentence was.

Indexing passages, not pages

So we stopped indexing pages. Quill now splits every page into passages: a heading and the paragraphs under it, a list, a table row, a decision. A typical workspace of 2,000 pages becomes about 61,000 passages. Each passage keeps a pointer to its page, its heading path and its owner.

A search runs in two stages. The first is a fast keyword and synonym match across every passage, which narrows 61,000 candidates to about 400. The second re-ranks those 400 by how well each passage answers the question as asked, using a small model we run on our own servers. Nothing leaves our infrastructure, and nothing a customer writes is used to train it.

query: "how many days of leave do new parents get"
stage 1: 61,204 passages → 412 candidates  (11 ms)
stage 2: 412 candidates → top 10 ranked   (148 ms)
answer:  Handbook / People / Parental leave, paragraph 1

The result page shows the passage itself, highlighted, with its page path above it. Click it and you land on that exact paragraph, scrolled into view.

Trust is a ranking signal

The second idea took longer to get right. Two passages can both answer a question, and only one of them is still true. Every page in Quill has an owner and a verification date, and since release 4.11 search uses both.

  • A passage on a page verified in the last ninety days gets a boost.
  • A passage on a stale page ranks below any verified passage that answers as well, and carries a quiet “stale” label.
  • A closed decision that changed a page outranks the old paragraph it replaced.

On our own workspace, that moved the correct answer into the first result for 71% of searches, up from 58%. The bigger change was qualitative: people stopped opening three results to cross-check them.

Decisions are searchable too

A surprising share of questions are not “what is the rule” but “why is this the rule.” Search covers the decision log and closed discussions, so “why did we drop the Friday deploy” returns the decision from March, who made it and the thread behind it.

Speed

All of this has to feel instant or nobody uses it. Our budget is 200 milliseconds from keystroke to results, measured at the 95th percentile from Chicago, our median customer location. Today we are at 164 milliseconds. The two things that got us there were keeping each workspace’s passage index in memory on one machine, and cancelling the stage-two re-rank the moment a new keystroke arrives, so a fast typist never waits on a stale query.

What is next

We are working on two things for the fall. The first is answers that span pages: when the leave policy lives in one page and the payroll detail in another, show both passages together. The second is the empty result. When search finds nothing, it should offer to open a discussion on the closest page and ask the owner, so the next person who searches finds an answer.

Search is the most-used feature in Quill by a wide margin, about 31 searches per person per week. It is also the one where small gains compound, so we will keep writing about it.